I think we should not just list urls but follow a struct more similar to the contact feild for examples:

{
  "endpoints": [
    {
      "method": "http",
      "endpoint": "https://fake.mint.dev"
    },
    {
      "method": "nostr",
      "endpoint": "nprofile1qs..."
    },
    {
      "method": "tor",
      "endpoint": "abcdefghijklmn.onion"
    }
  ]
}

I think we should not just list urls but follow a struct more similar to the contact feild for examples:

🤷 URI schemes were invented exactly for this reason. I am just not a big fan of using JSON dicts and I think it would have been much better if contact field also used URI schemes instead of the abomination we have now. :-) That said I don't mind either way and I always prefer consistency over "correctness". If there is consensus to go with the JSON dict instead of the URI scheme, I will update the PR.

TokenV4 has a field m for the mint URL: https://cashubtc.github.io/nuts/00/#token-format_1

Consider the following scenario:

Let's say mint Bob in accessible on 2 URLs. If Alice has a token for Bob's mint (with "Bob URL 1" embedded) and sends this token to Carol, then Carol will only have "Bob URL 1" to get to the mint. If the mint becomes unreachable on URL 1 but remains reachable on it's URL 2, Carol won't know the 2nd URL and won't be able to redeem it.

Is that true, or am I missing something?

The fix would be for TokenV4 to include all of Bob's known URLs, but that would mean making the token bigger (esp. with tor URLs).

Consider the following scenario:

That is exactly what I described here: #62 (comment)

Merged in cdk cashubtc/cdk#398

Merged in nutshell cashubtc/nutshell#638

ACK 6f55ebf